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1 Background of the Invention 

2 Field of the Invention: 

3 The present invention is generally related to public network 

4 connected data repository systems used to store user-information and, in 

5 particular, to a network-accessible secure repository server system that stores 

6 confidential user-information for access by third-parties subject to user and system 

7 defined constraints and conditions. 
8 

9 Description of the Related Art: 

10 The use of the Internet and other public and private networks to 

1 1 transfer confidential user information continues to grow. In particular, business- 

12 to-consumer and business-to-business electronic commerce (e-commerce) sites 

13 require secure electronic transactions involving confidential user information to 

14 complete purchases. Other sites rely on confidential user information to tailor 

1 5 their site appearance and store prior activities for the benefit of individual users. 

1 6 While some information may be stored on the user computer systems in the form 

17 of cookies, the typical requirement is for the user to explicitly establish a site 

18 account, with a unique site-identity, to store confidential user-information 

1 9 persistently with the site. 

20 With each new site-account established, the user is burdened with the 

21 requirement of maintaining a record of the account, managing the stored user 

22 information, and handling the status and confirmations of transactions conducted 

23 through each account. This typically requires the user to independently remember 

24 a unique user name and password for each account, manually update each and 

25 every active merchant account with any changes in billing address, shipping 
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1 address and credit card information, and to individually manage the processes 

2 of confirming electronic transactions, receiving transaction receipts, and 

3 monitoring the status of transactions not yet delivered. 

4 While the overall burden of managing an individual site-account may not 

5 be large, a typical user will often have a relatively large number of such accounts. 

6 As a result, the total burden of fully maintaining more than a few accounts 

7 becomes rather impractical. Even for businesses needing to maintain accounts 

8 with multiple merchant vendors, the individuality of the site-account presentations, 

9 modification methods, and information requirements represents a substantial 

10 burden. 

1 1 The nature and effects of this burden have been recognized for some time. 

12 A number of potential solutions have been implemented in various manners, 

1 3 though with only marginal success. These solutions are generally categorized as 

1 4 electronic wallets, or data repositories, where the confidential user data is stored 

15 locally on the user's own computer system or on a remote, network connected, 

16 centralized repository server. Conventional e-wallets, however, have failed to 

17 become more than marginally accepted or used for a variety of fundamental 

18 reasons. 

1 9 For example, local e-wallet applications, such as Gator™ (www.gator.com), 

20 provides somewhat limited security for user information stored on the user 

21 computer system. In operation, the application intercepts URL requests to selected 

22 Web pages, typically the order checkout-form pages, of e-commerce sites 

23 previously recorded in the application's local repository, which also records the 

24 form layout and data requirements of each page. Some layout and requirements 

25 analysis may be performed by the application to account for discrepancies and 
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1 changes in the Web pages with the result that recognizable form fields are filled-in 

2 by the application based on the user information stored in the local repository. 

3 This analysis capability is typically extended to attempt to identify Web-form pages 

4 and then recognize the specific data requirements of these pages. 

5 The ability of e-wallet applications to reliably discern the specific data 

6 requirements of different fields on unknown Web-page forms from multiple 

7 unknown sites, and even known sites with changed Web-page forms, is lacking. 

8 A significant degree of user intervention is required to compensate for 

9 unpredictable form identification and data requirement errors. Furthermore, the 

1 0 matching and processing of available user data to the specific data requirements 

11 of a Web-page form is also often unreliable, resulting in the potential for user 

12 information to be improperly submitted. 

13 Thus, conventional local e-wallet applications have failed to gain 

14 acceptance due to a variety of reasons, including limited ability for the user to 

15 differentially control access to the user's information, inadequate security 

1 6 protections, inability to access the e-wallet information globally, and too frequent 

1 7 unreliable identification the data requirements and fill-in of particular fields in ever 

1 8 changing Web-page forms. 

1 9 Conventional remotely located repository applications, such as Microsoft® 

20 Passport (www.passport.com), use a network server as a central repository for 

21 confidential user information. Other, typically e-commerce servers are required 

22 to tightly integrate with the Passport server in order to securely and reliably request 

23 and receive confidential user information. The Web-page form owner is therefore 

24 required to maintain all form fields in strict conformance with the requirements of 

25 the Passport system in order to receive information from the remote repository 
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1 server. There is also little or no flexibility for the definition and use of form-fields 

2 uniquely required, let alone desired, by a particular participating site. 

3 Consequently, any participating site must adopt a specific and proprietary coding 

4 nomenclature for binding the Passport system to their Web-page form fields. 

5 These integration requirements are recognized to be beyond the practical 

6 capabilities of non-commercial sites. Further, the inability to define and use 

7 unique fields greatly restricts the Passport system from being used by sites with 

8 non-generic user data requirements. 

9 The burdensome design, implementation, and management requirements 

10 imposed on each participating site, as well as the enforced inflexibility for 

1 1 handling new and unique types of information represents a substantial barrier to 

12 more than marginal acceptance of such remote repository systems. While 

1 3 conventional Passport-type systems generally provide much stronger security over 

14 confidential user data and, by definition, reliability to fill-in forms, they provide 

1 5 little or insufficient user capabilities to manage user data and differentially control 

1 6 access to that information by participating sites. For these reasons, the Passport 

1 7 system has met with very limited adoption. 

18 A public standard, known as the Electronic Commerce Modeling Language 

19 or ECML (www.ecml.org), has been proposed and met with some limited 

20 acceptance. This standard, in effect, merely defines a limited set of names for 

21 form fields used by merchants to define a credit-card e-commerce transaction. 

22 The defined fields allow specification of a shipping address, billing address, 

23 receipt address, the essential details of single credit card, and a very small set of 

24 order management fields including little more than an order ID field and a 

25 transaction complete field. Thus, the field definitions are sufficient for an e- 
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1 commerce merchant to submit a credit card number for validation with the card 

2 issuer's databases. The ECML standard does not, however, provide for any actual 

3 implementation. Rather, the ECML field definitions allow e-commerce system 

4 vendors to implement their own credit-card validation services with only a 

5 potential for interoperability based on the form naming convention. Further, no 

6 provision is made for supporting the validation or storage and retrieval of any 

7 additional, let alone non-credit-card, information. 

8 Consequently, none of the known repository- based systems are capable 

9 of meeting the broad needs of users to store and define access to their user 

10 information in a manner that is secure, flexible enough for use among many 

1 1 participating sites, and sufficiently easy to adopt and maintain by both users and 

12 the many different types of potential participating sites. 
13 

14 Summary of the Invention 

15 Thus, a general purpose of the present invention is to provide for the 

16 secure storage of flexibly-defined confidential user information from a remote 

1 7 repository server and selective provision of the information to any site partnered 

1 8 with the remote repository server system subject to flexibly-defined constraints and 

19 conditions. 

20 This is achieved in the present invention by establishing a repository server 

21 system to store confidential user-information for selective distribution, on behalf 

22 of a user to third-party server systems to enable autonomous form data fill-in of 

23 named form fields having third-party server defined data formats. A database is 

24 utilized to store the confidential user-information data in named data fields. A 

25 repository server processor is coupleable to the database to obtain access to the 
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1 confidential user-information. The processor is also coupleable to a 

2 communications network to receive a form data request issued by the third-party 

3 server. The form data request includes a predefined selective mapping of named 

4 form fields relative to the named data fields. The processor operates over the 

5 selective mapping to access the confidential user-information data and produce 

6 instances of the confidential user-information data corresponding to the defined 

7 data formats of the named form fields. A form data response, then returned to 

8 the third-party server system, contains the confidential user-information data 

9 corresponding to the defined data formats of the named form fields. 

10 Selective delivery of confidential user-information is also achieved in the 

1 1 present invention by providing a user identification system that establishes secure 

12 and selectively controlled release of information associated with a user 

13 identification. The repository server system supports secure network 

1 4 communications with a user and with third-party sites remote from the repository 

15 server system. The user and third-party sites pre-establish user and third-party 

1 6 accounts with the repository server system, each receiving an identifying reference 

1 7 recognizable by the server system. The request for information received by the 

18 repository server system includes the third-party identity reference and is 

19 accompanied by the client identity reference. User account data access in 

20 response to the received request is first qualified by data access rules established 

2 1 by the user. Depending on these user established data access rules, the repository 

22 server system selectively initiates a communications session with the user, in effect, 

23 while the received request is pending with the repository server system, to obtain 

24 user responses to the request for and approve release of the user-information to 

25 the third-party site. 
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1 The repository server system can thus support one-click retrieval of user 

2 data over a communications network in fulfillment of the data requirements of a 

3 Web page form as served to the user computer system. The Web page form is 

4 provided with a clickable user interface control which encompasses a user data 

5 request, issuable by the user computer system and that corresponds to the Web 

6 page form. The repository server system is responsive to the user data request to 

7 provide a user data response, corresponding to the user data request, to the user 

8 computer system. 

9 An advantage of the present invention is that a flexible profiling system 

10 allows the user to define and control any and all particular confidential user- 

1 1 information that can be accessed, altered, and provided to individual partner 

1 2 sites. The partner sites may be further constrained by a repository enforced typing 

1 3 of any partner to further protect against the inappropriate accessing, altering, or 

1 4 provision of confidential user-information to partner sites. Additionally, a system 

15 of sub-profiles or related profiles to be established to allow users of designated 

16 accounts to access, alter, and use the confidential user-information of a primary 

1 7 account, within profile defined limits established by the owner/user of the primary 

18 account. Within this profiling system, transient use accounts can be established 

19 to support one-time or time-limited transaction accesses to profile defined 

20 confidential user-information. 

21 Another advantage of the present invention is that a requested set of 

22 confidential user-information can be provided to a partner site with little or no 

23 interaction with the user. A user-interface control, invoked by a single-click user 

24 action or autonomously activated by the loading of a Web page, initiates the 

25 information request, with pre-qualified confidential user-information then being 
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1 returned to the partner site. The pre-qualification of confidential user-information 

2 is constrained by the profile and partner site typing functions of the present 

3 invention. Thus, the pre-qualification of confidential user-information may flexibly 

4 release specific confidential user-information automatically or require the user to 

5 confirm release of specific confidential user-information received. 

6 A further advantage of the present invention is that relatively little 

7 configuration, programming, or management burden is placed on the partner 

8 sites in connection with the utilization of the present invention. Integration of the 

9 partner sites with the secure information server of the present invention requires, 

1 0 in preferred embodiments, a single, simple post-processing step to process a new 

1 1 or revised Web page. The post-processing provides a user-interface control 

1 2 button coded with the request for the confidential user-information required to fill- 

1 3 in the form presented by the Web page. The Web-page developer need only then 

14 place the button on the Web page to complete the integration of that particular 

1 5 page with the repository server system of the present invention. Furthermore, the 

16 partner site is not required to change their form processing code and processes 

1 7 in order to integrate with the secure information server of the present invention, 

18 which reduces implementation complexity and time. 

1 9 Still another advantage of the present invention is that a user can securely 

20 and reliably fill-in a partner site Web page form with no more than a single 

21 mouse click. Once a user has at least indirectly logged onto the information 

22 server, a secure, time limited session is established allowing a partner site to 

23 request and transparently receive confidential user-information pre-authorized by 

24 the user for release to that partner site. A single click can be used, as in the case 

25 of a login, to initiate the partner site request. Alternately, a single click may be 
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1 used to confirm the acceptance of the form as filled-in. No click may be required 

2 where the partner site is permitted to autonomously request the fill-in information 

3 and where the applicable partner-site profile established by the user does not 

4 specify a use-acknowledgment click. 

5 Yet another advantage of the present invention is that the information 

6 requests and transfers are routed through the user's computer. Encryption of the 

7 information released, as well as all information provided or edited by the user, is 

8 therefore enforced by the information server. For transactions between a user and 

9 partner site requiring or just desiring user-identity validation, the establishment of 

10 the information server account and subsequent authenticating email, postal, 

1 1 encrypted key-card contacts allows authentication of the client-user to the 

12 information server. This information may be securely passed directly to the 

1 3 partner site to authenticate a user. Alternately, the information server may provide 

1 4 its own authentication credentials to the partner site as a proxy for the client-user, 

15 where present and prior interactions between the information server and client- 

1 6 user are of a sufficient nature to warrant proxy validation. 

17 A still further advantage of the present invention is that all accesses to the 

1 8 information stored in a user account and all requests for and releases of data can 

1 9 be logged and reported to the user by email, post, or through the account directly. 

20 Additionally, information provided from a partner as a receipt in connection with 

21 some transaction can be captured and stored for the user in the user account. 

22 Capture of this information informs the user of the nature of the transaction and, 

23 also, the particular profile used and data released in connection with the 

24 transaction. The transaction confirmations and the collection of transaction 
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1 receipts both serve as checks against unadvised and fraudulent use of the 

2 confidential user-information. 

3 Still another advantage of the present invention is that it provides a number 

4 of security capabilities, some pro-active and others based on usage reports 

5 provided to the user. A proactive security measure includes the prevention of 

6 identical credit card information being entered in two or more unrelated user 

7 accounts existing on the information server. A reporting measure is that all 

8 transactions are logged and are available to being viewed. Since the information 

9 requests are routed through the user's computer, the IP address and other 

1 0 identifying information may be logged along with the information provided by the 

1 1 partner site. Also, the partner site is preferably required to establish an account 

12 with the information server. Thus, the information server may enforce a positive 

1 3 identification of the partner site, optionally including a reverse-DNS match, before 

14 any information is released/ 
15 

16 Brief Description of the Drawings 

17 These and other advantages and features of the present invention will 

18 become better understood upon consideration of the following detailed 

1 9 description of the invention when considered in connection with the accompanying 

20 drawings, in which like reference numerals designate like parts throughout the 

21 figures thereof, and wherein: 

22 Figure 1 is a block diagram of the network communications system 

23 environment that the present invention is preferably directed; 
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1 


Figure 2a is a process flow diagram of a preferred method of operation 


2 


between a partner site, user, and information server system in accordance with a 


3 


preferred embodiment of the present invention; 


4 


Figure 2b is a representative view of an exemplary partner site form and 


5 


active button for initiating an information request connection, on behalf of a 


6 


partner site to an information server system in accordance with a preferred 


7 


embodiment of the present invention; 


8 


Figure 3 is a block diagram of the processes and procedures implemented 


9 


by an information server system in a preferred embodiment of the present 


O 10 

'it 


invention; 


11 


Figure 4 is a process flow diagram of the partner site system request for 


! s .3 r 


and receipt of information from an information server system in accordance with 


13 


a preferred embodiment of the present invention; 


4= 14 


Figure 5 is a process flow diagram of an information server system 


H 15 


handling and responding to information requests from a partner site; 


l:i i6 


Figure 6 is a process flow diagram detail of the parsing of an information 


y 17 

□ 


or other request received by an information server system in accordance with a 


Q 18 


preferred embodiment of the present invention; 


19 


Figure 7 is a process flow diagram showing the preferred post-processing 


20 


integration of an information server system with a partner-site Web page form; 


21 


and 


22 


Figure 8 is a process flow diagram showing the preferred pre-processing 


23 


integration of an information server system with a partner-site receipts posting 


24 


Web page. 


25 
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1 Detailed Description of the Invention 

2 As generally illustrated in Figure 1 , the environment preferably addressed 

3 by the present invention includes a typically public-use communications network 

4 12, such as the Internet, that permits a user of a client system 14 to conduct 

5 information transactions over the network 1 2 with any of the partner site servers 

6 1 6, 1 8, 20 and an information server system 22. The partner site servers 1 6, 1 8, 

7 20 represent any network accessible computer systems that provide or require a 

8 login identification by the user, that request form-entry type information, or that 

9 may submit information, such as receipts, on behalf of a user to the information 

10 server system 22. The partner site servers 16, 18, 20 may be electronic 

1 1 commerce sites, where the user is allowed to order or purchase goods or services. 

12 Site-specific Web page forms are presented to the user to obtain identifying 

13 information, such as a login name and password, and other transaction-specific 

14 information prior to completing a user transaction. Electronic receipts and 

15 receipt-type data, generated in connection with an ecommerce transaction or 

16 independently generated and supplied, such as in the case of warranty and 

17 product registration, and purchase incentive coupons, are preferably received 

1 8 from partner sites. 

19 In accordance with the present invention, the partner site servers 16, 18, 

20 20, present an additional user-interface (Ul) control, such as a clickable button, 

21 on Web pages to allow a user to initiate the retrieval of confidential user- 

22 information desired to complete a specific data-entry form. The Ul control may 

23 also be used to initiate or cause the submission of receipts or receipt-type data for 

24 storage with the information server system for the benefit of the user. Other 

25 controls, such as check-boxes, selection lists, and radio buttons, as well as pre-set 
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1 site and user-specific site configuration options, can be used as alternative 

2 interface controls. 

3 In the case of a Web page form, the user activation of a user-interface 

4 control, either directly as through a button click or indirectly through the triggering 

5 of a pre-set, a request is issued, preferably using an HTTP Get command or 

6 alternately a Post command, on behalf of the corresponding partner site server 

7 16, 1 8, 20 destined for an information server system 22 that includes a processor 

8 system 24 that manages and controls access to an information repository 26. 

9 When received, the request contains or is accompanied by sufficient information 

1 0 to authenticate the partner site server 16, 18, 20 and the client system 1 4 to the 

1 1 information server system 22. The request also identifies the information needed 

1 2 to complete the partner site form presented to the user. This identification of the 

13 information requested can be an explicit coded listing of the requested 

14 information. Alternately, the identifier is an indirect reference, which is 

15 processable by the information server system 22, to obtain a corresponding list 

1 6 of the requested information. Preferably, the identifier is constructed as a hybrid, 

1 7 containing explicit data field references for handling dynamic data requirements 

1 8 and a storage reference for data field references that are well anticipated or static. 

1 9 Using the hybrid specification of data references allows the dynamic or run-time 

20 complementing and overriding of the static set of data field references. 

21 In each of these cases, each form field is named such that when this 

22 requested information is returned to the partner site, each datum returned is 

23 named with a corresponding field name which is the partner site form field 

24 assigned name, functionally allowing the form to be autonomously filled-in. 
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1 Consequently, a single button click, which may be implicitly provided where a pre- 

2 set is used, is all that is required to complete a form presented by a partner site. 

3 To operate within the preferred embodiments of the present invention, the 

4 user is required to initially establish a user-account on the information server 

5 system 22. In establishing this account, the user is allowed to select or is assigned 

6 a unique user-identifier, such as a username and password. This identifier, 

7 potentially further based on an encrypted key token, is used to subsequently 

8 identify the user to a partner server system 16, 18, 20 that has established a 

9 partner-account with the information server system 22. 

10 As part of creating or later updating the user account, the user is enabled 

11 to provide and store confidential user-information, broadly defined as any 

1 2 information that is reasonably personal to the user, such as name, age, shipping, 

13 billing, and home addresses, multiple credit card information, social security 

14 number, telephone numbers, medical record numbers, personal interests lists, 

15 wish lists, receipts, registrations, survey answers, other use data and files, and 

16 various user-oriented and partner site-oriented preferences. Preferably, the user 

17 is permitted to establish different named profiles and aliases for information 

1 8 subsets stored in the user account. In general, the profiles define particular user- 

19 controlled views to the confidential user-information stored in the user-account. 

20 For example, different sets of credit card information, shipping addresses, and 

2 1 other relevant information may be directly named or aliased to descriptive names, 

22 provided by and easily identified by the user, used to describe general uses, such 

23 as business, medical, and personal or particular uses, such as a specific corporate 

24 travel account. These named profiles can then be identified or associated for use 

25 with other profiles used, for example, to identify specific partner sites and include 
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1 other confidential user-information, allowing the user to define site-specific and 

2 role-based constraints on the information that may be modified or released. 

3 Named profiles, such as "login only/' "company purchase plan/ 7 and "games/ 7 

4 may be established for use in constructing other site-specific profiles. Preferences 

5 may be stored globally by the information server system 22 for controlling, 

6 constraining, and defining the interoperation of the information server system 22 

7 individually with partner site servers 16, 18, 20 and with the user. Overriding 

8 preferences may be established in individual profiles for closely controlling, 

9 constraining, and defining the interoperation of the information server system 22 

10 with specific partner site servers 1 6, 1 8, 20 and the user. 

1 1 Profiles that establish roles for partner sites that do not then have partner 

12 site accounts established may, in preferred implementations, provide for the 

1 3 creation of such accounts. Thus, for example, a restricted access profile created 

14 to allow a doctor or laboratory to transfer in and review profile defined medical 

15 , data also creates an account for the doctor or laboratory if one is not pre-existing. 

16 Time-limited accounts established to provide payment to incidental vendors of 

17 goods can also be supported by a user's creation of a corresponding time and 

18 value limited user profile. Similarly, a profile providing a limited credit-line usage 

19 of a parent's credit card, potentially further limited in terms of allowed product- 

20 type purchases that can be made, enables the user of the identified child account 

21 to access and use the data within the parent account subject to the profile 

22 limitations. 

23 Preferably then, each partner site server 16, 18, 20 is also required to 

24 establish a partner-account, which is specific to one or more sites, on the 

25 information server system 22. The partner-accounts are each assigned a unique 
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1 identifier, which must be provided with any partner-site information request. The 

2 information server system 22 also requires coordinated receipt of the user- 

3 identifier. In accordance with the present invention, the user-identifier is 

4 independently provided from a client system stored cookie directly to the 

5 information server system 22. The user-identifier is not provided to the partner- 

6 site. The required independent receipt of both the partner and user-identifiers, 

7 which are only commonly known to the information server system 22 provide a 

8 significant level of authentication of the partner site servers 16, 18, 20, as well 

9 as the client system. The partner-accounts may also store data defining additional 

1 0 authentication protocols that can be used to ensure that server impersonation is 

1 1 precluded. Another use of the partner-accounts is to provide storage for mapping 

12 tables for converting between well-known data codings, as used by the 

13 information server system 22, and any alternate coding set used by a particular 

1 4 partner site. Other information, such as the identification of a different URL to be 

15 used for returning user information or particular requirements of a particular 

16 partner site server, can also be stored in individual partner accounts. 

17 A preferred transactional implementation of the process of the present 

18 invention is shown in Figures 2a and 2b. The process flow 30 preferably starts 

19 with user actions 32, typically Web navigational transactions with some partner 

20 site server 16, that results in the user being presented with a form 52 to be 

21 completed 54, 56. This form includes the user-interface control 58, hereinafter 

22 referred to as the OnelD™ button, which is coded with an HTTP Get command for 

23 issuance to the URL of the information server system 22, all provided in 

24 accordance with the present invention. The HTTP Get command also preferably 

25 includes the partner-identifier and one or more identifiers that identify or represent 
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1 the confidential user-information requested by the partner site server 16. Since 

2 the information server system 22 is known to the partner site server 1 6, the target 

3 URL of the information server system 22 can be pre-emptively specified with 

4 respect to a particular Get command. Conversely, the partner site URL is either 

5 also coded into the Get command or available by lookup by the information 

6 server system 22. 

7 When the user selects the user- interface control 58, the HTTP Get 

8 command is finally prepared and issued by the client computer system 14, in 

9 effect, on behalf of the partner site server 16. This final preparation include 

1 0 incorporation of client system specific data, such as transaction specific identifiers 

1 1 and values, to be included in the Get command. The issuance of the Get 

1 2 command by the client system 14, as opposed to the partner site server, allows 

1 3 information from the client system 1 4 to be included independent and unseen by 

1 4 the partner site server 1 6. The issuance of the Get command allows cookies and 

1 5 potentially other data from the client computer system 1 4 to be passed on to the 

16 information server system 22 as part of or associated with the Get command. 

17 The issuance of the HTTP Get command and included information is 

18 preferably performed using a secure protocol, such as provided by a secure 

19 transactions layer, such as the Secure Sockets Layer (SSL). Use of the secure 

20 protocol is preferably maintained as between the partner-site server 16, client 

21 system 14, and information server system 22 until a response to the issued request 

22 is eventually returned to the partner-site server 16. Preferably, the information 

23 server system 22 requires secure transactions between the client system 14 and 

24 the information server system 22 whenever confidential user-information is being 

25 manipulated. 
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1 


The client system 14 participates substantively in each communication 


2 


transaction involving the information server system 22 and any of the partner site 


3 


servers 1 6, 1 8, 20. With each data transaction, the client system 1 4 provides any 


4 


applicable cookies stored by the client system to the information server system 22. 


5 


Preferably, this cookie data includes an identification of the client system 14 and 


6 


a time signature representing the user of the client system 14 is logged in on the 


7 


information server system 22. The cookie containing the time signature is 


8 


preferably stored on the client system 14 as a transient cookie with a short time- 


9 


to-expiration limit as set by the information server system 22. Each 


? 10 


communication between the client system 14 and the information server system 


") 1 1 

i si 


22 may replace or update any or all applicable cookies stored by the client system 




14. 


?i 13 


Issuance of the HTTP Get command to the information server system 22 


14 


gives effect to a top level or overarching transaction between the information 


H 15 


server system 22 and a partner site system 1 6. In response to the receipt of this 


hi 16 


Get command, the information server system 22 may execute any number of 


Li J 


intervening HTTP or other transactions with the client system 36 or simply return 


□ 18 


fhe requested data in a Get response to the client system 1 4 with the partner site 


19 


system 16 as the effective target. The client transactions preferably include, but 


20 


are not limited to the set of transactions set forth in Table 1. 


21 


Table 1 


22 


Client/Information Server System Transactions 


23 


Loqin: 


24 


the client time signature cookie has expired or has been removed; a login 


25 


screen for the information server system 22 is presented to the user of the 


26 


client system 14. 
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Table I 

Client/Information Server System Transactions 

1 Profile Choice and Confirmation: 

2 no profile has been assigned to this partner server 1 6 or if assigned, has not 

3 been enabled for autonomous response to the request; a profile choice or 

4 confirmation screen is presented to the user of the client system 14. 

5 Profile and Information Server System Data Update: 

6 the form data requested by the partner server system 16 is not in the 

7 selected profile or is not stored by the information server system 22; the user 

8 is presented with screens to select a different profile, enable the requested 

9 information to be visible in a selected profile, use the existing available data 

1 0 in responding to the partner server system 1 6, or to enter the data into the 

1 1 information server system 22; data that is required by the partner server 

12 system 16 is distinguished from optional data identified in the request. 

13 Create and Edit Profiles: 

14 the user may create new profiles and revise existing profiles to contain 

15 specific sets of information; new information may also be provided for 

16 storage by the information server system 22 and, thus, made available for 

1 7 inclusion in any of the profiles; any profile may be marked for autonomous 

18 use in response to a request from a particular partner site server 1 6, marked 

19 to require confirmation before responding to a data request by any 

20 particular partner site server 1 8 or marked to offer the creation or selection 

21 of a profile corresponding the requested data where no profile has prior 

22 assigned to a particular partner site server 20. 

23 Messages and Warnings: 

24 a message or warning is presented to the user where invalid or unknown 

25 data is requested by any partner site server, where the partner site server 

26 account has been closed or terminated, or where the partner site server or 

27 client system login cannot be authenticated. 

28 

29 A response to the form data request by the partner site server 16 is 

30 potentially supplemented and approved 36 by the user of the client system 14 

31 through actions taken in intervening HTTP transactions with the information server 
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1 system 22. Where the user is not already logged in to the information server 

2 system 22, an applicable profile requires the confirmation of the release of some 

3 confidential user-information, or the responsive information is either not available 

4 within the applicable profile or user-account altogether, suitable Web page forms 

5 are preferably generated and presented to the user for completion. This new 

6 confidential user-information is then stored by the information server system 22 

7 and made available through whatever profiles are designated by the user. 

8 Conversely, where the user is logged-in to the information server system 22 and 

9 the requested confidential user-information is cleared for automatic release to at 

10 least the requesting partner-site, no overt confirming user action 36 is required, 

1 1 Once the release of confidential user-information is approved, whether 

1 2 directly or indirectly, the applicable profile-delimited responsive data is returned 

13 as a response to the initial Get command issued by the client system 1 4 on behalf 

1 4 of the partner site server 1 6. The client system response 38 in turn provides form 

1 5 data to the partner site server 1 6, along with any applicable partner-site cookies. 

1 6 As part of the Get command response processing, the named fields of the form 

1 7 are filled-in. If all of the requested field data identified by the partner site server 

18 16 as required is received, the partner site server 16 may simply proceed and 

19 process the form using the provided data. This is preferably the action taken 

20 when the form represents a login request for the partner site server 1 6. 

21 Alternately, the partner site server 1 6 may autonomously utilize the form 

22 with the provided data and await further user actions 40, such as the entry of 

23 additional form data or an explicit submission request from the client system 14. 

24 Such further form data may be information for required form data fields not 

25 provided by the information server system 22 or possibly to encourage the user 
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1 to complete optional data fields not filled in with data from the information server 

2 system 22. In either case, a submission button or the like is conventionally 

3 provided by the partner site server 1 6 on the form page to enable the user to 

4 signal that the form has been completed to the extent desired by the user. 

5 The information server system 22 and particularly the server processor 24 

6 is detailed in Figure 3. The processor 24 preferably includes a network interface 

7 60 that connects with the network 12. A security module 62, preferably 

8 implementing the SSL protocol and included as a software component within a 

9 HTML, WAP, XML or other Web server 64, operates as an interface to the network 

10 interface 60. Information, such as the component parts of the form data received 

1 1 in response to an HTTP Get command/are provided through the Web server 64 

12 to a process manager 66. This process manager 66 may be implemented as a 

13 server-side application. In any particular implementation, the process manager 

14 66 preferably operates to stage the series of events needed to respond to 

15 whatever Web request that is presented to the network interface 60. Some of 

16 these steps may entail the preparation and presentation of information on a 

1 7 virtual or remote interactive user- interface 68 to a user of the client system 1 4 to, 

18 for example, permit additional information to be entered into the corresponding 

1 9 user record as stored in the data repository 26 or present messages and warnings 

20 to the client system 14 and potentially to the partner site server 1 6. 

21 Any data from the user and partner account records, is provided 

22 individually or collectively 70 from some number of supporting processes 72^. 

23 This information may be requested by and returned to the process manager 66 

24 and the virtual interactive user- interface 68. These processes 72^ variously 
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1 support the client system 1 4 and partner site server 1 6 requests and may include, 

2 but are not limited, to the processes identified in Table II. 

3 Table II 

4 Information Server System Processes 

5 Authentication Process: 

6 supports the verification that specified client and partner accounts are active 

7 and that any provided IDs, passwords, certificates or tokens are valid. 

8 Profile Process: 

9 supports the selection of profiles as well as the creation and editing of 

10 profile preferences and contents. 

1 1 Form Fill-in Process: 

1 2 supports the identification and selection of data corresponding to the codes 

13 provided with a form data request, including resolving code to available 

14 data ambiguities, from an identified profile. 

15 Transaction Process: 

16 supports the suspension of a current form data request while potentially 

17 multiple user transactions are executed in support of other processes. 

18 Receipts and Receipts-type Data Reporting Process: 

19 supports the collection, updating, and reporting of user receipts, coupons, 

20 registration acknowledgments, and other receipt-type data. 

21 Transaction History Process: 

22 supports the identification and reporting of user and partner detailed 

23 purchase and other activity history records 

24 Data Update Process: 

25 support information server system requests presented a user to obtain 

26 particular data, such as may be needed to suffice a form data request, and 

27 to record the details of individual purchase transactions for both the partner 

28 and client users. 

29 

30 As generally shown, the information provided by the supporting processes 

31 72^ is returned to the process manager 66 or the virtual interactive user-interface 
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1 68, based on the identified source of the information request. The process 

2 manager 66 may process this information to determine whether any further steps 

3 are necessary before returning data to the client system 14. For example, the 

4 form fill-in process 72 3 may indicate either that an assigned profile does not 

5 include all or, at least, the required data requested or that the user record simply 

6 does not contain some part of the data requested. Thus, depending on the 

7 particular response of the form fill-in processor, the process manager 66 may 

8 choose to invoke other processes 72^, such as the transaction process 72 4 , the 

9 profile process 72 2 , and the data update process 72 N . 

1 0 The data needed to support transactions with the user are prepared by the 

11 virtual interactive user-interface 68 and forwarded on to the client system 14 

12 through the HTML server 64. Similarly, the data responsive ultimately to a partner 

13 site server 16 request is prepared and returned through the HTML server 64. 

14 The support processes 72 } _ N may, as appropriate, communicate data to 

15 and from the data repository 26. These communications are preferably supported 

1 6 through a software interface 74 to an object or relational database management 

17 system that, in turn, manages the reading and writing of account records stored 

18 by the data repository 26. Using an object database management system may 

19 be preferred. 

20 Referring now to Figure 4, a preferred partner site server 16 process is 

21 presented. The partner site server 16, in response to web navigation commands 

22 presents 82 a form, such as form 52, to the user of a client system 1 4. The user 

23 may simply choose to complete the form directly and continue 84 with the partner 

24 site server 16 controlled process. Alternately, the user may choose to invoke a 

25 repository access process by clicking 86 the provided button 58. In response, the 
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1 client system 1 4 issues 88 the button embedded predefined coded request for the 

2 information needed to complete the form. Preferably, required information is 

3 distinguished from optionally entered information in the coded request. This 

4 coded request preferably contains a URL containing a Get command and 

5 identifications of the source partner site server 1 6 and target information server 

6 system 22. The Get command also preferably contains a reference to a mapping 

7 of the named form fields for which information is requested and the 

8 corresponding data fields supported by the information server system 22. 

9 Preferably, the mapping is predefined and stored, in part, by the information 

10 server system 22. 

1 1 A response to the coded request is preferably received 90 and parsed 92 

1 2 to recover the coded information returned. This information is then used to fill-in 

1 3 94 the form presented by the partner site server 1 6. Additional codings or other 

1 4 information may also be returned to the partner site server 1 6 to specify whether 

15 the filled-in form should be redisplayed to the user and await further user input 

16 or be automatically submitted to the partner site server 16 for continued 84 

17 processing. 

1 8 Where the network transmission of the response is incomplete or invalid, 

19 a failure report may be issued 96 to the user and, preferably, to the partner site 

20 server 1 6. The user notification at least allows the user to be aware of the failure. 

21 The notification to the partner site server 16 preferably enables continued 

22 processing 84 through an error management routine that may simply reissue the 

23 coded request to the information server system 22 or present the user with the 

24 choice to abort or reinitiate the process of requesting information from the 

25 information server system 22. 
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1 A partner site server 1 6 can provide receipt-type data to the information 

2 server system 22. While this data may be submitted autonomously by the partner 

3 site server 1 6, preferably a Web page containing the information to be submitted, 

4 in effect a pseudo-form page, is presented to the user. Either in response to a 

5 button click 86 initiating the submission of the data or a page display trigger, the 

6 data is prepared 1 02 by associating each component of the data with an explicit 

7 data field name supported by the information server system 22, or a pseudo-field 

8 name that is then mapped to a corresponding data field name. Where the 

9 receipt-type data is dynamically generated by the partner site server, the content 

10 of the Get command, or alternately a Post command, must be dynamically 

1 1 prepared 100. A URL including the Get command data then built 102 and sent 

12 88. The response received 94 is preferably a confirmation acknowledgment 

13 message 98, indicating that the data has been received and appropriately 

1 4 handled by the information server system 22. After receiving an acknowledgment, 

15 the partner site server 16 continues 84 typically to interact with the user of the 

16 client system 14. Where a negative acknowledgment or some other failure 

1 7 message is received, the failure is reported 96 preferably to the partner site server 

18 16, which can the continue 84 and handle the error condition. 

19 The preferred information server system 22 process is shown in Figure 5. 

20 Inbound requests from a client system 1 4 are received 1 1 2 as information server 

21 requests. This request is automatically coupled with a client time-signature cookie, 

22 if available. If the signature cookie is not present or has expired, the user is 

23 permitted to logon 1 14. Provided there is a successful login, the data from an 

24 expired time signature cookie is replaced by the new login information. 
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1 The request is then examined to retrieve the account information, including 

2 the partner-identifier, of the partner site server 16. The client-identifier is 

3 obtained from the client cookie or newly logged in account. In performing an 

4 account lookup 116, if either account is not found or is not active, a failure 

5 message 1 18 is returned by the information server system 22. Where both site 

6 accounts are found and are active, a site coded request function is identified 1 20 

7 from the request. Typically, the site function identifies a specific request for data 

8 to fill-in a form. The profiles defined in the user-account, as stored by the data 

9 repository 26, are then examined to identify 1 22 a profile associated specifically 

10 or by general criteria with the identified partner site server 1 6. If such a profile is 

11 not found, the user may be prompted to enable setup of a new site 124, 

1 2 producing update data reflecting a change in the associated user account, which 

1 3 is then updated 1 26 to the data repository 26. Where a new site is setup or where 

14 no profile is associated with a prior setup of the site, or where the site-identified 

15 profile is set to require a re-selection of the applicable profile, the user is 

16 presented with a form-based opportunity to select and apply an existing profile 

17 from the user account. Where a profile is selected, the user account is 

1 8 correspondingly updated 1 26. The user is then permitted to immediately use the 

19 selected profile or setup 130 and select a new profile for the identified site. In 

20 both instances, the user is preferably also permitted to edit 130 the selected 

21 profile. 

22 The selected profile is then qualified, particularly as to whether sufficient 

23 information is present in or through the profile to fully respond to the outstanding 

24 information request. A new data query, if needed, is presented 134 to the user 

25 to enable profile access to data stored at large in the user account and to obtain 
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1 information identified in the information request but not present in the user 

2 account. In the former case, the selected profile is updated 1 26 to indicate that 

3 additional information is at least logically included in the selected profile. In the 

4 later case, the new information entered is updated 126 to the user account and 

5 again the selected profile is updated 1 26 to indicate that additional information 

6 is at least logically included in the selected profile. 

7 The selected profile is also qualified 1 32 as to whether use of the profile 

8 is pre-approved for automatic response or requires user approval prior to a 

9 response being issued back to the partner site server 1 6. Where use of the profile 

1 0 is pre-approved, the request responsive data is collected from the selected profile, 

1 1 coded into Get response and issued 1 36 to the client system 1 4 for further return 

12 to the partner site server 16. Where user approval 138 is required, the user is 

13 presented with a confirmation form, preferably including an identification of the 

14 current information to be submitted to the partner site server 1 6. The user may 

1 5 then approve issuance 1 36 of the response, select another profile 1 28, create a 

1 6 new profile 1 30, and edit 1 30 the selected profile. 

1 7 Another partner site function is the submission, by a partner site server 1 6, 

18 of receipt-type data, which may include data describing a single purchase 

1 9 transaction, a historical set of transactions, and other activity data for storage in 

20 the user account. Such activity data is recovered 1 40 from the partner site server 

21 16 request. The data is updated 126 to the data repository 26. An 

22 acknowledgment of the successful updating of the user account data may 

23 optionally be returned to the partner site server 16. In similar fashion, other 

24 function identified actions 142 may be recognized 120 and suitable responses 
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1 prepared. These responses may be presented as acknowledgments 1 44 or coded 

2 responses 136 containing data obtained from the data repository 26. 

3 Figure 6 shows a preferred process flow 150 for user interactions directly 

4 with the information server system 22 from the client system 1 4. User interactions 

5 are preferably supported through a public Web site (not shown) and, in general, 

6 presented as one or more Web pages containing the selections available to the 

7 user and fields that enable user entry and editing of the data stored in an account 

8 record. This Web site is preferably hosted by or on behalf of the information 

9 server system 22. The Web site may thus be considered part of the information 

i. 

{ 1 0 server system 22. 

t 

I 1 1 When a selection or entry is submitted by the user, the resulting URL 

| 

1 12 packaged request is submitted, received and examined 1 12. If the accompanying 

I 1 3 time signature cookie is present and not expired, the request embedded within the 

14 received URL is further examined to recover the identified function 120 selected 

* 15 by the user. Alternately, where the time signature cookie has expired, the 

t 16 information server system 22 presents the user with a login screen 1 14 prior to 

i 

[ 17 further examination of the received request. 

J 18 Any number of different function requests can be submitted to the 

19 information server system 22. Choice of a specific function may be by a user 

20 through a subsequent, more detailed selection list presented as a secure Web 

21 page form to the user. As represented in Figure 6, a report of partner transaction 

22 data and other historical information may be requested. A report is prepared 1 54 

23 and returned 156 to the user preferably as another Web page. Similarly, a 

24 function requesting a status check 1 58 of pending purchases results ultimately in 

25 the preparation 1 60 of a corresponding status report and return 1 56 of the status 
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1 


report as a Web page. Receipt-type data can also be reviewed 1 62 and reported 


2 


1 64 to the user. 


3 


The information system server 22 preferably responds to a function request 


4 


ultimately specifying the modification of some account record data by presenting 


5 


a corresponding Web page to permit entry of the modifications. Such 


6 


modification may include the editing 1 66 of profiles, the informational contents 


7 


of the account data, the specific and general association of profiles with partner 


8 


sites, and various user account and profile preferences. The modified data, when 


9 


submitted back 168 to the information server system 22, is stored in the user 


i io 


account. An acknowledgment of the secure receipt and storage of the data may 


. 5 


then be returned 156 by the information server system 22. Alternately, a 


.a* 

H 12 


confirmation Web page may be presented to allow the user to verify the data 


I] I 3 


before being committed to the user account within the data repository 26. 


■»• 14 


Other operations on the user account can be similarly provided by pre- 


t I 5 


establishing an identifiable 120 request-type. Execution of the corresponding 


.!! i6 


function can then be performed by the information server system to return 156 an 


:i( 17 


appropriate response to the user. 


::i is 


The preferred process 1 76 of integrating the information server system 22, 


19 


in accordance with the present invention, with the Web page forms of a partner 


20 


site 16 is shown in Figure 7. In order to ease and place a minimum burden on 


21 


the development and maintenance of partner site Web page forms, the preferred 


22 • 


process is implemented as a post-processing step relative to the design and 


23 


development 1 78 of a Web page form. The post-processing step begins with the 


24 


submission of the Web page form to a software mapping tool hosted, directly or 


25 


indirectly by the information server system 22. In order to submit the Web page 
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form, the developer utilizes an interactive process 180 to receive a login form. 
The developer is preferably required to login to the partner site account and 
request the submission of the Web page form 182. The submission process is 
carried out by uploading the Web page form code through a form provided by 
the information server system 22. The upload may be specified by the developer 
providing a URL to the form page and initiated by a button click leading to an 
activity data transfer of the Web page code directly to the information server 
system 22. Alternate manners of submitting a Web page form, such as through 
pasting, can be supported. 

When received, the Web page form code is passed to a backend process 
1 84 to be parsed 1 86. This parsing operates to identify the names of the form 
fields embedded in the Web page form. Based on the names parsed from the 
form, a mapping display process is then executed to define, to a reasonable 
extent, a likely mapping of the form field names to the names of the data fields 
defined for the data repository 26. The resulting mapping table is then passed to 
the interactive process 180 for display 190 to the Web page developer. The 
displayed form allows the developer to correct and complete the association of 
form field names to data field names. While a form field name such as "First 
Name" could be autonomously mapped to a likely corresponding data field 
named // $o_firstname$/ / a form field name "PrimaryN" is unlikely to be correctly 
mapped to "$o_firstname$." The mapping form preferably allows form field 
names to be associated with data field names using a simple clickable interface. 

Another mapping issue handled by the mapping tool of the present 
invention involves specifying value format conversions. Preferably, the mapping 
form allows a Web page form developer to construct value format conversions 
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1 using parsing, logical combination, concatenation, translation, and other 

2 functions and operators. Conversions defined using these functions and 

3 operators are applied against identified data fields of the data repository to create 

4 a value format conversion appropriate for returning data from the information 

5 server system 22 in a manner that matches the desired value format of a Web 

6 page form field. 

7 For example, where a single form field requires a full name, a format 

8 conversion is required where the data repository separately carries first, middle, 

9 and last names. For a form field name of "p_name" and data field names 

10 // $o_firstname$/ / "$o_middlename$," "$o_lastname$," a value format 

1 1 conversion can be constructed using concatenation as: 

12 pjname=$o_firstname$ + $o_middlename$ + $oJastname$. 
13 

1 4 Format conversions are also required where, for example, a date must be 

1 5 provided in a locale specific format or credit card numbers must be provided with 

1 6 particular punctuation or broken-up into four component number fields for entry. 

1 7 To provide punctuation, specifically using a colon in this example, a value format 

1 8 conversion for a form field named p_creditcard number can be constructed using 

19 parsing and concatenation: 

20 $oa_l$=$subst(o_ccnumber, 1,4)$; 

21 $oa_2$=$subst(o_ccnumber, 5,8)$; 

22 $oa_3$ = $subst(o_ccnumber, 9,12)$; 

23 $oa_4$ = $subst(o_ccnumber, 13, 16)$; 

24 p_creditcardnum=$oa_l$%3A$oa_2$%3A$oa_3$%3A$oa_4$; 
25 
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1 where %3A is the encoded format of 

2 Other instances and types of format conversions can be numerous. Since 

3 the value format conversion is performed by the information server system 22, a 

4 flexible and, as needed, large library of conversion functions and operators may 

5 be maintained universally for use by Web page developers. 

6 Predefined, or aliased, conversions are preferably also supported by the 

7 mapping tool. In the preferred embodiments of the present invention a date data 

8 field is aliased to a number of locale specific date data fields. Referencing the 

9 data field name of an aliased date data field is recognized by the information 

10 server system 22 as requiring a corresponding conversion. Thus for a form field 

1 1 name"p_date,"a mapping of "p_date=$o_dateEPIocale$" is logically expanded 

12 and executed as: 

13 p_date=$european_date(o_date )$; 

14 where the pre-defined function "europeanjdate" provides the appropriate 

15 conversion. Thus, many common conversions may be easily represented as 

16 merely alternative data repository data field names. Such pre-supplied conversion 

17 function aliases, combined with the potential of allowing a developer to store 

1 8 custom conversion functions in the partner site account, greatly eases the process 

19 of defining the form field name mapping. 

20 In connection with performing field name mapping, the present invention 

21 permits the Web page form developer to define and name custom or "dynamic" 

22 data fields 1 96 and then map form field names to those data fields. This allows 

23 the Web page developer to expand the base of information carried by the 

24 information server system 22 on behalf of the partner site server 1 6. When a user 

25 encounters a Web page form that includes a dynamic data field, the information 



Attorney Docket No.: PRPL3013 

gbr/prpl/3013.000.application.wpd 



12/12/2000 



-34- 

server system 22 will present the field to the user for completion in the same 
manner that predefined data repository 26 fields are presented to request data 
entry or prompted for inclusion in the current applicable profile. Where data is 
provided to the information server system 22 for a custom data field, the data 
object representing the profile is preferably extended to provide storage for the 
entered data. Subsequently, references from the partner site server 16 to the 
dynamic data field name will return the corresponding stored data. As the 
creation and subsequent management of the dynamically created data fields is 
handled for the partner site server 1 6, the only significant requirement placed on 
the Web page developer is to associate their assigned data field name with a 
consistent definition or understanding of what the stored data represents. Since 
this definition is specific to the partner site account, the developer is well capable 
of maintaining such a definition. 

Once the mapping 1 90 of a Web page form is completed, the developer 
submits the mapping 1 98 for generation 200 of a map coding block. Preferably, 
this map coding block includes a structured set of mapping statements, such as 
those illustrated above. In a preferred embodiment of the present invention, a 
generated map coding block will be of the general form: 

http://www.oneid.com/site/partner.jsp? // target URL 
method = post // transport method 

&sid = 230776 // partner-identifier 

&action=form_encode(formpage_URL) // source URL 
&p_map=form_encode( \ 

p_date=$o_dateEPIocale$& \ 

p_name=$o_firstname$+$o_middlename$+$o_lastname$& \ 
$oa_1 $=$subst(o_ccnumber, 1,4)$& \ 
$oa_2$=$subst(o_ccnumber, 5,8)$& \ 
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1 $oa_3$=$subst(o_ccnumber / 9,1 2)$& \ 

2 $oa_4$=$subst(o_ccnumber, 13, 16)$&\ 

3 p_creditcardnum=$oa_l$%3A$oa_2$%3A$oa_3$%3A$oa_4$&\ 

4 pfieldnamel =lib_conversionX($o_datafieldnameA$) 

5 ) 
6 

7 The generated map coding block is then wrapped 202 preferably with the 

8 HTML coding for a simple Ul button 58. The resulting Ul code, including the map 

9 coding block is then presented to the developer for download 204. In connection 

10 with the preferred embodiments of the present invention, the developer will then 

1 1 need only to insert 206 the downloaded Ul code in the previously prepared form 

12 Web page in a manner that visually places the Ul button 58 at an appropriate 

1 3 location on the Web page form. The Web page form is then ready to publish 208 

14 using any conventional Web page deployment tool. 

15 An alternate process 210 of using the software mapping tool is shown in 

16 Figure 8. The process 210 may be used where the Web page developer wishes 

17 to use the mapping tool before preparation of a Web page form 178. The 

18 process 210 is perhaps more typically used where the developer is preparing a 

19 receipts-type data display Web page and wishes to submit the data to the 

20 information server system 22. In either case, the mapping tool is used as a pre- 

21 processing-type step to generate Ul code that can be included on a Web page. 

22 Similar to the process 176, the developer initiates 212 the mapping 

23 process 210 by logging in and setting 214 the tool to a pre-processing mode. A 

24 comprehensive mapping table is prepared. The mapping display 190 is then 

25 presented to the developer. While place-holder field names may be defined and 

26 used to map against the data repository data fields, the developer may choose to 

27 directly use the data repository data field names. These place-holder field names 
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1 areusedaspseudo-filed names, since a dynamically generated receipts-type Web 

2 page will not include any form fields. These pseudo-field names are therefore 

3 assigned by the developer to different data elements presented on the receipts- 

4 type Web page as part of the mapping 1 92. The pseudo-field names may be of 

5 particular use where the presented data must be converted to a value format 

6 defined by a data repository data field, generally as described above. Alternately, 

7 use of data repository data field alias names may be sufficient to implicitly convert 

8 the developer chosen format of the receipts-type data to a value format 

9 appropriate for storage in the data repository 26. 

1 0 Mapping 1 92, value format data conversion 1 96, as well as the creation 

1 1 of dynamic fields for storing unique receipts related data, such as a shirt pattern 

12 type, size, or other information descriptive of the receipted transaction, are all 

1 3 available to the developer through the mapping display 1 90. Once the mapping 

14 190 is complete, the mapping is submitted 198, a map coding block generated 

15 200, and preferably wrapped with the HTML coding for a simple Ul button 58. 

16 The resulting Ul code is then presented for downloading 216 to the developer. 

1 7 Once retrieved, the Ul code can then be used in the preparation of the Web page 

1 8 form or receipts-type data page 2 1 8 by the developer. When completed, the Web 

19 page can then be published using a conventional deployment tool. 

20 Thus, a user identification system, including the capability maintain and 

21 securely supply user data to third-party sites, has been described. While the 

22 present invention has been described particularly with reference to HTML and 

23 Web page based transactions, the present invention is equally applicable to e- 

24 commerce sites utilizing other and additional communications and data sharing 
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1 protocols, including eHTML, XML, SGML, and wireless systems. The present 

2 invention is also applicable to any site that presents a form for user data fill-in. 

3 In view of the above description of the preferred embodiments of the 

4 present invention, many modifications and variations of the disclosed 

5 embodiments will be readily appreciated by those of skill in the art. It is therefore 

6 to be understood that, within the scope of the appended claims, the invention may 

7 be practiced otherwise than as specifically described above. 
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